Digital certificate with software enabling indicator

ABSTRACT

A server computer has a network interface circuit and a processing circuit. The network interface circuit is configured to provide communications over a network. The processing circuit is configured to transmit over the network an electronic document comprising a digitally signed identity associated with the server computer. The electronic document further comprises a software enabling indicator, the software enabling indicator comprising data indicating whether a software feature of a system is to be enabled for use.

BACKGROUND

The present application relates to enabling software features on acomputing device.

Software product licensing uses several methods to ensure that onlylegitimate users can use the software application. These methods rangefrom static license keys (a.k.a. serial licenses) to dedicated licenseservers, such as FlexNet Publisher. Current methods provide differentdegrees of security at the expense of deployment and maintenancecomplexity. While use of simple static license keys are the leastcomplex, they offer a limited amount of protection and functionality.License servers are the most complex, while offering the highest levelof protection, but are more costly. Further, in the case of a periodiclicense, when the expiration date is reached, the license file will beregenerated and provided by the vendor to the end user for update. Suchsystems do not scale well in time as the license cannot be dynamicallyrevoked by the vendor, once it has been issued.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram of a computing system for enabling softwarefeatures, according to an illustrative embodiment;

FIG. 2 is a diagram illustrating an electronic document having adigitally signed identity, according to an illustrative embodiment;

FIG. 3 is a diagram illustrating an electronic document having adigitally signed identity, according to another illustrative embodiment;and

FIG. 4 is a sequence diagram illustrating electronic documenttransmissions, according to illustrative embodiments.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

One or more embodiments described herein may fit between the twoextremes of simple static license keys and advanced dedicated licenseservers to provide sufficient security while being dynamically scalable.

One or more embodiments described herein may use Secure Socket Layer(SSL) certificates that are used for authentication of connectivity onthe Internet.

One or more embodiments described herein may still use a serial licensekey for the installation; however, they will add the ability todynamically enable or disable system features, in both time and space,from a central corporate location down to an individual device.

One or more embodiments described herein may provide time variationcapability by using changes to certificates at the corporate office,thus effectively affecting granted licenses immediately.

One or more embodiments may provide space variation capability by usingchanges to individual certificates, thus affecting only a singleinstallation of the system or multiple systems at the same time.

One or more embodiments may provide protection from reverse engineeringefforts of the client device's communication interface, as allfunctionality of the interface would be disabled until a validcertificate is received, thus preventing any communication with thedevice.

One or more embodiments may provide data sufficient to perform assettracking functionality, where a local server computer would report to acorporate server certificates usage by individual devices, thusproviding basic information about devices being in or out of servicewith a connection to specific local server host.

One or more embodiments may provide a secure licensing process, asexchange of SSL certificates may occur over a secure channel with thepublic key infrastructure built into the Transport Layer Security (TLS)mechanism.

One or more embodiments may provide for authentication against theserver from which a certificate came, so that the authorized licensingcannot be changed or modified by unauthorized parties. The licensingmechanism itself may be protected by a digital certificate according tohow SSL certificates are issued.

Referring now to FIG. 1, a system 10 for enabling a software featureusing a digitally signed electronic document is shown. In thisembodiment, system 10 is illustrated as being used with a medical device16 for performing a medical procedure on a patient, such as an apheresismachine. An apheresis machine is a machine configured to provideextracorporeal therapy to a patient by removing the patient or donor'sblood, separating out one or more constituents of the blood (e.g., redblood cells, white blood cells, plasma, etc.), and returning theremaining constituents to the patient. A centrifuge device may be usedfor the separation. Exemplary apheresis devices include the Amicusseparator, Alyx component collection system, Autopheresis-C system, andAurora Plasmapheresis system, all manufactured by Fenwal, Inc., aFresenius Kabi Company, Lake Zurich, Ill. In alternative embodiments,components or features of system 10 may be used with other medicaldevices, such as infusion pumps, patient monitors, medical imagingmachines, etc., and/or with other computing devices.

Devices 16, acting as client computing devices in this illustration, arecomputing devices configured to operate software features. Softwarefeatures can be applications, programs, extensions of a program, newversions of programs, enhancements or modifications of programs,software modules, or other software features. Different softwarefeatures may provide different functions available to a user of device16, such as a remote diagnostic feature, a remote control feature, aremote programming feature, a reporting feature for reporting data aboutprocedures performed using device 16, remote backup and restore, newuser interface features, audible alarm features, or any of a widevariety of software features. In this example, at least one, andoptionally a plurality of software features are programmed into memoryon device 16, for example during manufacture of device 16 or duringprogramming of device 16 (for example by downloading software featuresto device 16 using a local programming computer or downloading softwarefeatures from a remote server). Device 16 may be configured to enable ordisable software features programmed on device 16 in accordance withauthorization received from a remote device. In one example, device 16is programmed to operate one or more basic functions without requiringfurther authorization. Additional functions can be selectively enabledby device 16 in response to receipt of authorization. The authorizationmay come in the form of a static license key, a downloaded license key,or other authorizations, such as those described below.

System 10 comprises a server computer 12 and a server computer 14, inthis embodiment, though in alternative embodiments only one servercomputer may be used. Server computers 12 and 14 and device 16 areconfigured or programmed to perform steps described herein for enablingsoftware features. In alternate embodiments, server computers 12 and 14may be implemented on a single server computer, each implemented on aplurality of server computers, either or both implemented on a serverfarm, a cloud server environment, or using other computer resources.Devices 12, 14 and 16 may comprise analog and/or digital circuitcomponents forming one or more processing circuits configured to performthe steps described herein. The processing circuit may comprise discretecircuit elements and/or programmed integrated circuits, such as one ormore microprocessors, microcontrollers, analog-to-digital converters,application-specific integrated circuits (ASICs), programmable logic,printed circuit boards, and/or other circuit components. Device 16 maycomprise an embedded processor, such as a processor with a dedicatedfunction within a larger mechanical or electronic device, contrastedwith a general-purpose computer, such as a personal computer (PC). Oneor more of devices 12, 14 and 16 may each comprise a network interfacecircuit configured to provide communications over one or more networkswith each other and/or with other computing devices. The networkinterface circuit may comprise digital and/or analog circuit componentsconfigured to perform network communications functions. The networks maycomprise one or more of a wide variety of networks, such as wired orwireless networks, wide area-local-area or personal-area networks,proprietary or standards-based networks, etc. The networks may comprisenetworks such as an Ethernet network, networks operated according toBluetooth protocols, IEEE 802.11x protocols, cellular (TDMA, CDMA, GSM)networks, or other network protocols. The network interface circuits maybe configured for communication of one or more of these networks and maybe implemented in one or more different sub-circuits, such as networkcommunication cards, internal or external communication modules, etc.

In this illustrative embodiment, server computer 12, acting as asoftware enabling server or licensing server, is configured to transmitover the network an electronic document comprising a digitally signedidentity associated with the server computer. The electronic documentcomprises a software enabling indicator, the software enabling indicatorcomprising data indicating whether a software feature of a system is tobe enabled for use. The electronic document may be a digital certificateconfigured for establishing the authenticity of the identity of theserver computer to a remote device. A digital certificate (or identitycertificate or public key certificate) is an electronic document thatuses a digital signature to bind a key with an identity. An identity isdata such as the name of a person or an organization, their address, anickname, a trade name, or any other code which a person or organizationmay use to identify itself. A digital certificate can be used to verifythat a key, such as a public key, belongs to that person ororganization. The digital signature binds the key with the identitythrough any of a variety of strong or weak cryptographic mechanisms,such as a hash function, RSA encryption, the Rabin signature algorithm,the BLS signature scheme, or any other technique for digitally signingan identity.

The software enabling indicator is data that is used by the receivingcomputer of the digital certificate to determine whether a softwarefeature is to be enabled. For example, the software enabling indicatormay indicate that one or more client computing devices are licensed(e.g., pursuant to a software license agreement) to use the softwarefeature. In one example, a software enabling indicator may be a one-bitdigital flag (e.g., “1” or “0”, “yes” or “no”, etc.) in a field of adata structure known by the receiving computer to represent a particularsoftware feature. In another example, the software enabling indicatormay include a multi-character or multi-digit code representing the nameof a software feature along with an indication as to whether thesoftware feature is to be enabled (e.g., “yes” or “no”, “enable” or“disable”, “licensed” or “not licensed.”) In one embodiment, thesoftware enabling indicator is part of the electronic document that isdigitally signed. In other embodiments, the electronic documentcomprising the digitally signed identity may contain the softwareenabling indicator in an un-signed portion of the document.

The software enabling indicator in some embodiments may be a license keyor product key, such as a static license key. A product key consists ofa series of numbers and/or letters. This sequence is typically enteredby the user during the installation of computer software, and is thenpassed to a verification function in the program on the client computer.This function manipulates the key sequence according to a mathematicalalgorithm and attempts to match the results to a set of valid solutions.

Referring now to FIG. 2, an illustrative electronic document will bedescribed. Electronic document 20 comprises an identity data or code 22in a first field and a software enabling indicator 24 in a second field.In this example, both identity 22 and indicator 24 are digitally signedusing digital signature 26. Other data, codes, fields or extensions maybe used in various embodiments of an electronic document.

Referring now to FIG. 3, an alternative electronic document will bedescribed to illustrate a number of additional data elements that may bepart of electronic documents in alternative embodiments. Electronicdocument 30 comprises an identity in the form of a subject 32representing the identity of the certificate or website owner of theserver computer that is transmitting the electronic document to theclient computer. Document 30 further comprises a plurality of softwareenabling indicators 34A and 34B representing different software featuresto be enabled/disabled and perhaps in different formats (e.g., singlebit, multi-character, etc.). Document 30 further comprises: acertificate serial number 36, a unique identifier for this particulardocument 30 for use in distinguishing it from other documents; a versionnumber 38 which can be used for duplicate copies of the same document 30having minor changes (such as a renewed validity period, change insoftware enabling indicators, etc.); an algorithm ID 40 indicating acryptographic algorithm that was used to bind a certificate authority's(CA) digital signature (CA digital signature 54) to document 30; anotheridentity 42, this identity representing the name of the certificateauthority who digitally signed document 30 for use by the clientcomputer in determining whether the CA is in a predetermined list oftrusted CAs; a validity period 44 which comprises one or more validitydates, a validity date indicating a start date or end date of a periodduring which document 30 is valid and usable by client computer forauthentication; public key information for the subject 46, which maycomprise a public encryption key and a public key algorithm used withthe public key; issuer unique ID 48 and subject unique ID 50 areadditional optional identity fields; and optional extensions 52represents any of a number of additional data fields that may beinserted within electronic document 30.

In one example, the electronic document may be a Secure Socket Layer(SSL) certificate. The electronic document may be formatted inaccordance with the X.509 standard from the ITU TelecommunicationStandardization Sector. An SSL protocol may determine variables of theencryption for both the link and the data being transmitted.Communication of the electronic document may be in accordance with oneor more steps of a SSL transmission protocol, such as that describedbelow:

-   1. The client computer (e.g., operating a web browser) connects to a    server computer (e.g., operating a website) secured with SSL at a    URL preceded by https. The client computer requests that the server    identify itself.-   2. The server computer sends a copy of its SSL certificate,    including the server's public key.-   3. The client computer checks the issuer ID (also called the    certificate root) against a list of trusted issuers (e.g., CAs). The    client computer also checks that the certificate has not expired or    been revoked. If the client computer trusts the certificate, it    creates, encrypts, and sends back a symmetric session key using the    server's public key. The symmetric session key is used for    subsequent secure communication between server and client instead of    the public key because use of the session key provides faster    encryption/decryption of messages.-   4. The server computer decrypts the symmetric session key using its    private key and sends back an acknowledgement encrypted with the    session key to start the encrypted session.-   5. The server computer and client computer now encrypt all    transmitted data with the session key.

Referring again to FIG. 1, an illustrative system and method forenabling software features on devices 16 will be described. In thisexample, a two-step licensing model is implemented, where server 14 willobtain its licenses from a corporate license server 12, and individualdevices 16 will obtain their licenses by communicating with server 14.License server 12 may be implemented with a hypertext transfer protocol(HTTP) to provide self-signed SSL certificates to all instances ofservers 14 (three are shown, though more or less are contemplated), inresponse to periodic requests from servers 14. In addition to othercontent (such as that shown in FIGS. 2 and 3), the SSL certificates willinclude information about licensed features. When server 14 receives avalid SSL certificate, it will determine what features of server 14 canbe enabled. If a valid certificate is not received, server 14 willdisable licensed features and will operate only basic free functions.This will enable a manufacturer or servicer of devices 16, as acertificate authority, to dynamically grant or revoke licensed featuresby modifying SSL certificates with desired information (e.g., softwareenabling indicators) from the corporate location at any time. Onceserver 14 verifies its own licenses, it is configured to act as a proxyof license server 12 to connected devices 16.

According to one embodiment, the device communication interface (e.g.,network communication circuit) on each of devices 16 may be configuredto remain disabled until it receives a valid certificate from server 14.Once a valid certificate is received, device 16 is configured to enableits communication interface, for example for a specific period of timeor until it is powered off. When the device communication interface isenabled, server 14 will be able to communicate with device 16 toretrieve data (for example regarding medical procedures performed,regarding software features enabled/disabled, etc.), get statusinformation about device 14, set the device's configuration, etc.

Server 12 comprises a processing circuit configured to generate,request, and/or store an electronic document having a digitally signedidentity. Server 12 may perform these steps locally on server 12 or mayuse a local or remote authentication or signing server. For example,server 12 may be configured to generate a certificate signing request(CSR) document and transmit the CSR to a certificate issuer or CA, suchas DigiCert, Verisign, Entrust, etc. The CSR may be in a standardizedformat, such as Pkcs#10 or Spkac, or in a customized format. This CSRcreates a private key and a CSR data file that is sent to CA. The CAuses the CSR data file to create a public key to match the private keywithout compromising the key itself. The electronic document returned bythe CA is digitally signed by the CA. The CA is one that server computer14 and/or device 16 recognize as a trusted CA. The CA may be a thirdparty, or a manufacturer or servicer of devices 16. An SSL Certificateissued by a CA to an organization and its domain/website verifies that atrusted third party has authenticated that organization's identity.

Server 12 may be configured to embed or store the software enablingindicator or indicators (e.g., license key) in the electronic documentbefore the electronic document is digitally signed. Extensions or otherdata may also be inserted or stored in the electronic document before itis digitally signed. Alternatively, software enabling indicators,extensions or other data may be appended to the digitally signedelectronic document after signature.

Server computer 14 may be configured to periodically, intermittently,synchronously or asynchronously request communication with servercomputer 12. Alternatively, server 12 may make the request forcommunication of computer 14. In either case, server 12 may transmit thepreviously generated electronic document to server computer 14. Theelectronic document may be transmitted each time there is communicationfirst being established between server 14 and server 12 (e.g., uponpower-up of device 16, server 14 and/or server 12, each time there areinterruptions in the communication link, once per day, etc.). Servercomputer 14 may be configured to authenticate server computer 12 usingthe electronic document, for example using SSL techniques or othertechniques. If authentication is successful (e.g., a valid certificateis received, having a proper validity date, trusted CA, etc.), server 14is configured to read the software enabling indicator(s) and to carryout the instructions represented by the indicator(s). For example, if asoftware enabling indicator indicates that a license to use a softwarefeature has expired, server 14 may be configured to disable thatsoftware feature on one or more of devices 16, per the instructions. Asanother example, if a software enabling indicator indicates that alicense to use a software feature is now in place, server 14 may beconfigured to enable that software feature on one or more of devices 16.

In one embodiment, the validity date 44 of the electronic document maybe used by server 14 both for representing a date after which the servercomputer can no longer be authenticated using this electronic documentand for determining when the software feature is no longer enabled foruse. In alternate embodiments, the software enabling indicator mayseparately specify a validity date for a software feature. In eitherevent, server 14 may be configured to store in memory an indication ofsoftware features that are to be enabled, the number of licensesavailable, device 16 IDs that are to be enabled and a priority thereof,and/or other data useful for enabling and disabling software featuresbased on the electronic document received from server 12.

Server 14 may be configured to communicate over wired or wirelessconnections with devices 16, and may use encrypted or unencryptedcommunication techniques. In one embodiment, server 14 may be configuredto generate a plurality of electronic documents, each comprising adigitally signed identity associated with the server computer 14, theplurality of electronic documents each comprising a second softwareenabling indicator based on the first software enabling indicatorreceived from server 12. In this manner, server computer 14 acts as aproxy for server 12. Server 14 may be configured to transmit one of theplurality of electronic documents to each of a plurality of remotecomputing devices 15 for use in enabling a software feature on each ofthe remote computing devices 16. Server 14 may digitally sign theelectronic documents itself or may use a third party computer or evenserver computer 12 as a certificate authority for signing the electronicdocuments.

According to some embodiments, server computer 14 may be configured toreceive a first digital certificate having a software enabling code froma remote computer server over the network, generate a plurality ofsecond digital certificates based at least in part on the softwareenabling code, and transmit the second digital certificates to each of aplurality of client computing devices to be used by each clientcomputing device to enable a software feature. For example, the digitalcertificate received by server computer 14 may specify a number oflicenses that server computer 14 is authorized to pass along to devices16. Server computer 14 may be configured to prioritize which devices 16receive licenses. Server computer 14 may be configured to reallocate alicense from one device 16 not in operation at the time to anotherdevice which is in operation at the time. Server computer 14 may beconfigured to generate one digital certificate for enabling the firstsoftware feature and another digital certificate for enabling a secondsoftware feature different than the first software feature. Eachenabling code may comprise data regarding the number of licenses server14 may allocate for that feature, e.g., software feature A=100 licenses;software feature B=10 licenses. Server computer 14 may be configured toallocate licenses based on care area, for example, intensive care unit,primary care unit, neonatal care unit, floors or areas of a hospitalbuilding, etc.

In one example, the electronic document from server 12 to server 14could include user-defined fields or areas. Such fields could add to theinformation a differentiation of licenses based on the center to whichdevice 16 belongs. One server 14 may serves more than one center withdifferent devices. The license user-defined data space could include thecenter name and the features and the license keys for a first centername and a center name, features and license keys for a second centerwith different license keys than the first center. Further, server 14could generate certificates for individual devices 16 based on a singlecertificate generated for the center, and potentially for the wholemedical facility.

As discussed, device 16 may be configured to block, prevent, or rejectany attempt from outside device 16 for communication unless device 16receives a certificate it can verify with an authentic server. Device 14may function similarly. Typically in medical devices and embeddeddevices, the protocols are proprietary; so in order for a hacker orspoofer to understand what to send, they would need to haveprotocol-specific specifications. By preventing communication absent avalid certificate, even if an attempted spoofer was able to get thecorrect protocol specifications for communication with server 14 ordevice 16, the spoofer will not be able to communicate because it doesnot have a valid certificate. Thus, an added layer of security may beprovided.

Referring now to FIG. 4, a sequence diagram illustrates steps incommunication among device 16, server 14 and server 12. In a step 60,server 14 is configured to transmit a GetLicenseCertificate( ) requestmessage to server 12. This message may be an initial request forcommunication with server 12, submitted according to a TCP/IP protocol.Server 12 is configured to receive the request and generate and/orprovide a digital certificate DXTCertificate as described herein toserver 14. Server 14 is configured to determine whether the digitalcertificate is valid by comparing one or more of the certificateauthority to a prestored list of trusted CAs, the validity date to anactual date of receipt of the digital certificate, and/or other itemswithin the digital certificate. If the digital certificate is valid,server 14 is configured to enable licensed software features at step 62.If the digital certificate is valid, server 14 may further be configuredto generate device certificate(s) for device(s) 16 at step 64. If one ormore of the digital certificate validity checks does not indicate apositive result or that the digital certificate is valid, server 14 isconfigured to disable or not enable certain software features at step66. For example, if the software feature for a device is one that waspreviously enabled and now is no longer enabled, server 14 may beconfigured to generate and send a new digital certificate to device 16with an expired validity date as a way of indicating to device 16 thatthe software feature is invalid. In another example, server 14 may beconfigured to simply not enable the software feature on device 16 if ithas not yet been enabled. Other methods of disabling or not enabling asoftware feature based on an invalid digital certificate received atserver 14 are contemplated.

At step 68, device 16 may be configured to transmit aGetLicenseCertificate( ) message to server 14 to request an enablingmessage (such as a digital certificate or other enabling code) for asoftware feature or features to be authorized for use on device 16. Themessage may be sent asynchronously, such as when a device is powered onby a human operator, after a power outage or other cycling of power,etc. Alternatively, the message may be sent synchronously, such as onceper hour, once per day, etc. In response, server 14 may be configured togenerate and/or provide a digital certificate to device 16 comprising asoftware enabling code and/or other elements of a digital certificatedescribed herein. Device 16 comprises programming configured todetermine if the DeviceCertificate provided by server 14 is valid, againby comparing one or more elements to other data, such as the certificateauthority, validity date, etc. If the digital certificate is valid, thecommunication interface circuit of device 16 is enabled at step 70 foradditional communication, represented by the GetData( ) function (steep72), which is a generic function showing that once a valid certificateis in place, data transfer(s) related to licensed functionality mayoccur. If the digital certificate is not valid, the communicationinterface circuit remains disabled (step 74) (to communications beyondrequesting and receiving the digital certificate) so as not to allowcommunications from a potential spoofer. With a valid digitalcertificate, device 16 is configured to enable the software feature orfeatures specified by the digital certificate. The software features maythen be operable on device 16 for use by human operators, patients,clinicians, etc.

While some embodiments herein are described with reference to use withmedical devices, the teachings herein may be implemented in other fieldsas well, such as Internet web browsing, manufacturing, point-of-salecomputers, and a wide range of other computing environments.

1. A server computer, comprising: a network interface circuit configuredto communicate over a network; and a processing circuit configured totransmit over the network an electronic document comprising a digitallysigned identity associated with the server computer, the electronicdocument further comprising a software enabling indicator, the softwareenabling indicator comprising data indicating whether a software featureof a system is to be enabled for use.
 2. The server computer of claim 1,wherein the electronic document is a digital certificate configured forestablishing the authenticity of the identity of the server computer toa remote device.
 3. The server computer of claim 1, wherein theelectronic document comprises a public encryption key.
 4. The servercomputer of claim 1, wherein the electronic document is a Secure SocketLayer certificate.
 5. The server computer of claim 1, wherein thesoftware enabling code is a license key, wherein the processing circuitis configured to embed the license key in the electronic document beforethe electronic document is digitally signed.
 6. The server computer ofclaim 5, wherein the processing circuit is configured to embed avalidity date in the electronic document before the electronic documentis digitally signed.
 7. The server computer of claim 1, wherein thesoftware enabling code comprises an indication of a number of softwarelicenses for a plurality of client computing devices.
 8. The servercomputer of claim 7, wherein the software enabling code comprises anindication of software licenses for a plurality of different softwarefeatures.
 9. The server computer of claim 1, wherein the softwareenabling code comprises an indication of a first software license for aremote server computer and an indication of a plurality of secondsoftware licenses for client computers in communication with the remoteserver computer.
 10. A server computer, comprising: a network interfacecircuit configured to communicate over a network; and a processingcircuit configured to: receive over the network an electronic documentcomprising a digitally signed identity associated with a remote servercomputer, the electronic document further comprising a software enablingindicator, the software enabling indicator comprising data indicatingwhether a software feature of a system is to be enabled for use.
 11. Theserver computer of claim 10, wherein the processing circuit is furtherconfigured to authenticate the server computer using the electronicdocument.
 12. The server computer of claim 10, wherein the electronicdocument further comprises a validity date representing a date afterwhich the server computer can no longer be authenticated using thiselectronic document, wherein the processing circuit is furtherconfigured to store an indication that the software feature is no longerenabled for use after expiration of the validity date.
 13. The servercomputer of claim 10, wherein the processing circuit is furtherconfigured to: generate a plurality of electronic documents, eachcomprising a digitally signed identity associated with the servercomputer, the plurality of electronic documents each comprising a secondsoftware enabling indicator; and transmit one of the plurality ofelectronic documents to each of a plurality of remote computing devicesfor use in enabling a software feature on each of the remote computingdevices.
 14. The server computer of claim 10, wherein the electronicdocument is a Secure Socket Layer certificate.
 15. A server computer,comprising: a network interface circuit configured to communicate over anetwork; and a processing circuit configured to: receive a first digitalcertificate from a remote computer server over the network, the digitalcertificate comprising a software enabling code; generate a plurality ofsecond digital certificates based at least in part on the softwareenabling code; and transmit the second digital certificates to each of aplurality of client computing devices to be used by each clientcomputing device to enable a software feature.
 16. The server computerof claim 15, wherein the software enabling code comprises a first codefor enabling a first software feature and a second code for enabling asecond software feature, wherein the processing circuit is configured togenerate one second digital certificate for enabling the first softwarefeature and another second digital certificate for enabling the secondsoftware feature.
 17. The server computer of claim 16, wherein the firstcode represents a first number of licenses for use of the first softwarefeature and the second code represents a second number of licenses foruse of the second software feature.
 18. The server computer of claim 15,wherein the processing circuit is configured to transmit the one seconddigital certificate to a client computing device associated with a firstcare area within a medical facility and the another second digitalcertificate to a second client computing device associated with a secondcare area within the medical facility.
 19. The server computer of claim15, further comprising the plurality of client devices, wherein theplurality of client devices are medical devices.
 20. The server computerof claim 19, wherein the medical devices are apheresis machines orinfusion pumps.